home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19941031-19941221 / 000308_news@columbia.edu_Wed Nov 30 05:51:00 1994.msg < prev    next >
Internet Message Format  |  2020-01-01  |  3KB
  1. Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA03447
  2.   (5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Wed, 30 Nov 1994 03:58:42 -0500
  3. Received: by apakabar.cc.columbia.edu id AA10676
  4.   (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Wed, 30 Nov 1994 03:58:41 -0500
  5. Newsgroups: comp.protocols.kermit.misc
  6. Path: news.columbia.edu!sol.ctr.columbia.edu!math.ohio-state.edu!uwm.edu!news.alpha.net!news.mathworks.com!hookup!swrinde!howland.reston.ans.net!ix.netcom.com!netcom.com!jhurwit
  7. From: jhurwit@netcom.com (Jeffrey Hurwit)
  8. Subject: Re: MSKerm 3.14 BETA 14- APC security too strong?
  9. Message-Id: <jhurwitD02G90.6Bw@netcom.com>
  10. Organization: Organization?  What organization?
  11. X-Newsreader: TIN [version 1.2 PL1]
  12. References: <jhurwitD00M19.MnM@netcom.com> <3bfd3p$fkg@apakabar.cc.columbia.edu>
  13. Date: Wed, 30 Nov 1994 05:51:00 GMT
  14. Lines: 36
  15. Apparently-To: kermit.misc@watsun.cc.columbia.edu
  16.  
  17. In article <3bfd3p$fkg@apakabar.cc.columbia.edu>, Frank da Cruz
  18. (fdc@watsun.cc.columbia.edu) wrote:
  19.  
  20. >We get this complaint a lot, but there is no easy solution.  There is
  21. >a basic conflict between the need for host-directed operations such
  22. >as your script and the need to protect all MS-DOS Kermit users from
  23. >malicious attacks.
  24.  
  25. >If SET TERMINAL APC UNCHECKED could be issued by the host application,
  26. >then there would *be* no security.
  27.  
  28. >On balance, I think most would agree that inconvenience weighs less
  29. >than disaster.
  30.  
  31. >You should think of SET TERMINAL APC UNCHECKED the same way you think
  32. >about passwords.  You don't put passwords in scripts because the risk
  33. >far outweighs the convenience.  Thus whenever you run your login
  34. >script, you have it prompt you for your password.  Similarly, you shoul
  35. >SET TERM APC UNCHECKED before running your script and then put it back
  36. >to ON afterwards.
  37.  
  38.     Um, ok, I can accept this argument as far as it goes.  But, problem
  39.     is, if a macro or take file is invoked with an apc command, any
  40.     "unsafe" operations called for in those are also disabled.  So,
  41.     while I can understand wanting to protect some innocent user from a
  42.     malicious script or some such, what about having apc commands invoke
  43.     scripts that others are unlikely to know about?  Example:  The
  44.     script on my host account sends a compressed backup file,
  45.     backup.tgz, as backup.tmp.  The script on my PC receives the
  46.     transfer and, *if the transfer succeeds*, deletes the already
  47.     existing backup.tgz and renames backup.tmp to backup.tgz.  Would an
  48.     option to set apc unchecked for scripts only make any sense?  If
  49.     not, I guess I could always put the command in a macro and then bind
  50.     it to a key...
  51.  
  52.                         Jeff